(C) Copyright 1991, Massey University, N.Z., All Rights Reserved
CONTENTS
1. INTRODUCTION
2. AN OVERVIEW OF THE GAME
(a) Start
(b) In the field
(c) In the laboratory
(d) The diagnosis
(e) The de-briefing
3. BUILDING A SCENARIO USING DIAGBLD.EXE
4. USING THE GAME WITH STUDENTS
5. HARDWARE REQUIREMENTS
6. SUPPLIED SCENARIOS AND VPIC UTILITY PACKAGE
7. APPENDICES
1. INTRODUCTION
"Diagnosis" was written as a training tool for plant protection students
learning the "art" of disease diagnosis. The idea arose from the concept of
text-based adventure games, common on the old TRS-80's and Apple II's of
yesteryear. In an adventure game, the player is put in a situation where
clues must be found and deductions made in order to solve a puzzle and so
progress. In many respects, this "detective work" is similar to the process
of diagnosis. Clues are sought for in the field, and a tentative conclusion
reached which may or may not be confirmed in the laboratory.
By playing the game, it is hoped students will become aware of the critical
field and lab observations required for the real thing, as well as rising to,
and enjoying the challenge. The game is not designed to replace practical
hands-on sessions in the laboratory but rather supplement them. One advantage
it has over laboratory practicals is that it can monitor an individual
student's APPROACH to the problem both in the lab and the field. This is
difficult to asses using traditional teaching methods.
Features of "DIAGNOSIS" include....
* Teachers write their own "local" situations for students to solve thus the
program can be used anywhere in the world.
* The student's progress is monitored during the game and written to disk
for marking by the teacher concerned. Also, once students have
given a diagnosis they must justify their conclusion. This justification
is also written to disk for marking.
* If wanted by the tutor, the computer gives an instant de-briefing of what
the student should have or indeed did observe during their session and the
significance of the observations.
* Graphic pictures can be included. These are optional however, which means
the program can be run on a minimum configuration.
There are some limitations. The program is designed largely for fungal and
nematode plant diseases. It can be used quite successfully for insect pests,
virus/bacterial diseases and non-infectious disorders although the
confirmatory laboratory procedures, e.g. incubation chambers, DNA probes or
chemical leaf analysis, are not specifically available (in version 1.*
anyway).
It is assumed the teacher has a basic knowledge of MS-DOS and familiarity with
a text editor or wordprocessing package.
IF YOU DO NOT HAVE A GRAPHICS CARD CAPABLE OF 640 X 480 PIXELS AND 256
COLOURS, SOME OF PICTURES WILL NOT BE SHOWN FULLY. Part 6 of this text
explains what would normally be done about this in order for scenarios to be
used with a lesser graphics card. However, you will need DIAGBLD.EXE, which
is not supplied with this demo.
2. AN OVERVIEW OF THE GAME
(a) Start
The game consists of two programs, TITLE.EXE and DIAGNOSE.EXE linked together
in a batch file called DIAG.BAT. Running DIAG.BAT executes TITLE.EXE which
loads and shows an introductory graphic screen. The student is asked to input
their initials which are then placed in a TEXT file called PLAYER.NM.
TITLE.EXE then terminates and the batch file loads the main program
DIAGNOSE.EXE.
Upon starting, DIAGNOSE carries out several file operations. First, it reads
the name contained in the file DISEASE. This file contains the name of the
data file which was prepared by DIAGBLD.EXE (see later). In the supplied
demo it is CASE0.DAT but it can be any data file the teacher has prepared.
The program then loads in the data from this file. Next the program reads the
initials in PLAYER.NM and then opens a text file using the initials as the
file name. This file will receive all subsequent student input, which can be
printed out and marked after the game.
(b) In the field
The field scenario then appears on the top half of the screen. This will
remain on the screen until the student either moves to the laboratory for
further tests, or they feel they can make a confident diagnosis and quit.
The lower half of the screen contains the input and response area: Input
usually requires a verb and a noun unless otherwise directed although in some
cases a verb alone will illicit some action. Complex commands are broken
into two steps. For example, in response to the command 'ask grower' the
program will reply 'Ask grower about what..?' and the student will be
required to input a single noun.
The response to input can consists of textual and/or graphic information
depending entirely on how the scenario has been constructed using DIAGBLD.EXE.
Input is fully error-trapped, with impossible tasks (e.g. 'ask tree')
returning an appropriate response.
The vocabulary appears below with synonyms on the same line. In reality, the
program only uses the first four letters of each word.
Verbs
(i) Used with nouns
examine, inspect, observe, look, study, check
cut ,section, slice, dissect
smell, sniff
feel,
ask, talk (only useful when used with 'grower' or 'farmer')
get, take, obtain, collect, remove
eat (here the program gives a "stock" answer no matter what the object)
go, goto (only useful when used with 'laboratory')
(ii) Used alone
diagnosis, quit
panic
help
think
inventory (to see what's been collected)
Nouns
(i) Used with verbs
plant(s), tree(s), bush(es), shrub(s), vine(s)
leaves, leaf, foliage
stem(s), trunk(s), bark, crown(s), corm(s), base
seed(s), grain
branch(es), twig(s), shoot(s), cane(s)
flower(s), blossom(s)
root(s), tuber(s), rhizome(s)
fruit, berry, berries
weed(s)
soil, ground, earth
weather
grower, farmer (only useful when coupled with 'ask')
lab, laboratory (only useful when coupled with 'go or goto')
(ii) Used as a response to 'ask grower'
weather, rainfall, humidity, environment, temperature
fungicides, bacteriacides
insecticides, miticides, acaracides
herbicides, weedicides
sprays (asks player to be more specific)
fertiliser, manure, compost
drainage, flooding
irrigation, watering
variety, cultivar, type
history, past, management
The program keeps track of objects which are collected for use in the
laboratory later. What can and cannot be taken is dependent entirely on what
the 'scenario creator' (using DIAGBLD.EXE) has decided
(c) In the laboratory
After spending time in the field, the student will probably wish to spend time
in the laboratory to carry out extra tests on tissue they have collected.
However, this is optional, and players can omit this step simply by typing
'DIAGNOSIS' or 'QUIT' whilst in the field.
After typing 'GO LAB', the students are asked to give a preliminary diagnosis
based on the field observations they have just completed. They are then sent
to the laboratory for a closer examination of collected material.
In the lab, a split-screen is shown as before and the student selects one or
more common procedures to carry out. The material they have available for
examination depends on what they collected in the field.
As with the field, responses to input can consist of words and/or pictures,
depending on what went into the data file from DIAGBLD.EXE.
(d) The diagnosis
Once the student decides they know what the problem is, they are asked to give
a diagnosis and justify their answer in a few paragraphs. When this section
is finished the program goes into a de-briefing.
(e) The de-briefing
In setting up the data file with DIAGBLD.EXE, the 'scenario creator' can
specify up to 12 important 'clues' which the students will hopefully come
across during their investigations. The program keeps track of which clues
are uncovered during the run and in this section these are presented to the
student along with those they did not unearth. The correct diagnosis is also
given. The computer responses are written onto the student's input file to
help with assessment.
At the termination of the program, the text file recording student input is
closed and can be printed out later for marking.
Some tutors may wish to omit this de-briefing, particulary if a number of
students are going to try the same scenario at different times. If this is
the case, the file DIAGNOSE.EXE should be replaced with DIAGNODB.EXE (n.b. not
available in the demonstration version) in the DIAG.BAT file. An instant
de-briefing on the screen does not take place but it is still written to the
student's disk file.
3. BUILDING A SCENARIO USING "DIAGBLD.EXE"
(N.B. This file is not available in the DEMO version but the text below
explains what it does.)
(a) Introduction
One of the main features of the DIAGNOSIS package is the ability to create
many different disease scenarios. This is done using DIAGBLD.EXE.
DIAGBLD.EXE is similar to a compiler, taking a (source) text file and
converting it to a Pascal typed file, which DIAGNOSIS.EXE (or DIAGNODB.EXE)
then uses. In this case, the text file contains all the responses and other
controlling information required for the main program.
(b) Source text file
(i) Structure
The text file can be prepared with any text editor but it must be
ASCII only and free of any control codes. The content follows the
pattern outlined overleaf...
BEGIN
|...... Help available (Y/N)......|
|.........Field scenario..........|
| |
| |
|...Field Verb/Noun combinations..|
| |
| |
| |
| |
| |
| |
|........Grower responses.........|
| |
| |
| |
|.......Objects which can/........|
|........cannot be taken..........|
| |
| |
|..........Lab scenario...........|
| |
| |
|.........Lab procedures/.........|
|...... tissue combinations.......|
| |
| |
| |
| |
| |
|......Correct diagnosis..........|
| |
|......De-briefing intro..........|
| |
| |
|.....Responses to clues found....|
| |
| |
| |
|.....Responses to clues lost.....|
| |
| |
| |
|.....De-briefing conclusion......| Layout of source text
| | file for DIAGBLD.EXE
| |
|.......Graphics viewing..........|
|........program used.............|
END
The structure must be strictly controlled. It would be worthwhile now
looking at PHYTOROT.TXT distributed with the program. This is the text
file which produced CASE0.DAT. It is well commented and shows exactly
what is required. Read it through - it is largely self-explanatory.
Everything in upper case MUST ALWAYS be present and EXACTLY how it is
written. The text in lower case is the input provided by the scenario
creator. Text responses are limited to a certain number of lines
(but may be less) and are usually terminated by a "." as the first
character on a new line. Lines commencing with a "{" are ignored so
they can be used for comments. Blank lines are NOT ignored.
(ii) Graphics
Due to the large number of hardware configurations available, the
incorporation of graphics is always difficult in a program such as this.
DIAGNOSE.EXE does not handle graphic screens directly but instead can run
any user-supplied external graphics display program from within itself.
This being the case, it is up to the scenario creator to draw or "grab"
graphic screens using other software. The scenario creator can provide
his or her own graphics "show" software or use the supplied utility VPIC
(Copyrite Bob Montgomery, 543 Via Fontana #203, Altamonte Springs, FL
32714-3172, U.S.A.). Instructions for VPIC can be found in the file
VPIC.DOC. Also they will need to ensure no compatibility or memory
errors will result on the particular hardware the game is to be run.
Testing after construction will therefore be required.
If used, any graphic screen files (including command line switches) must
be recorded in the source text after the appropriate verb/noun
combination on the same line as the heading "PICTURE = " (see
PHYTOROT.TXT). If there are no graphics with that response, just write
"none".
Finally, at the end of the source file underneath "GRAPHICS SHOW PROGRAM"
the full name (including pathway if appropriate) of the executable file
which will display the graphic screens must be written. If no graphics
are to be shown the words "none" should be written.
The demonstration scenario uses the provided graphics picture
viewer VPIC.EXE. It must be configured (using "CONFIG.EXE") for
whatever graphics hardware configuration is being used.
The following is reiterated: AS BOTH DIAGNOSE.EXE AND DIAGNODB.EXE
RELINQUISH CONTROL TO AN EXTERNAL PROGRAM DURING A PICTURE CALL-UP, IT
IS UP TO THE SCENARIO CREATOR TO ENSURE THE CORRECT HARDWARE AND PICTURE
FILES ARE AVAILABLE. THE SOFTWARE CANNOT CHECK FOR ERRORS DURING THIS
TIME.
Also, there must be sufficient memory for both programs to co-exist.
To assist in the correct formatting of scenarios, a source text file template
(TEMPLATE.TXT) with all the formatting headings is available in the full
DIAGNOSIS package.
(c) Compiling with DIAGBLD.EXE
Once a source text file has been created (or TEMPLATE.TXT has been filled in),
DIAGBLD.EXE can be used to convert it into a typed data file (like CASE0.DAT).
Upon execution, the current directory is displayed and the source file and
data file name requested.
The program then reads the text in the source file and scrolls it on the
screen whilst it incorporates it into a data structure for writing to disk.
It also checks extensively for formatting errors at this time. If an error is
found, the program halts at the place it occured and prints a message. The
error must then be corrected using a text editor and the text recompiled.
Finally, if there are no errors, a message appears indicating the data file
has been successfully written to disk.
(d) Using the new scenario
To use the new scenario, the data file name must be placed as a single entry
in the text file DISEASE. DIAGNOSE.EXE will look in this file to obtain the
name of the data file to load. The reason for this two-step process, rather
than having DIAGBLD.EXE create a standard file (say "SCENARIO.DAT") which is
directly used by DIAGNOSE.EXE, is to prevent the need for constant renaming of
different scenarios and allow the scenario creator to easily identify which
data files contain particular scenarios.
DISEASE, the scenario data file, any graphic picture files and the appropriate
executable graphics show file should be in the same directory as DIAG.BAT
before running the software.
The above instructions are summarised as a series of steps in appendix 1.
4. USING THE GAME WITH STUDENTS
The game can be run on a network or alternatively students can be provided
with their own game disks each containing a single scenario out of however
many have been written. They can then return the disks for marking after
running the program. Obviously, these disk should NOT be write protected..
The disks should have the following files....
TITLE.EXE
TITLE.DAT (contains the title graphic and ask for student's initials)
DIAGNOSE.EXE (or DIAGNODB.EXE - see below)
DIAG.BAT (listing the two .EXE files above in the order they appear)
DISEASE (containing as its only entry the name of the scenario data file)
The scenario data file itself (e.g. CASE0.DAT or similar)
Graphic files and the graphic viewer (e.g. VPIC.EXE) if images are used.
Upon running the software, two new files will be created
PLAYER.NM (contains the students initials so DIAGNOSE.EXE can use them) and a
file whose name IS the students initials. The latter contains the student's
input.
The student input text file that is created while they play the game should
indicate just how they went about solving the problem. The most important
piece of text to mark will be the justification(s) for their diagnosis.
Teachers can decide their own marking criteria but obviously, this section
should carry considerable weight regarding the allocation of marks.
One problem which may arise is that of some students telling others the
solution before the latter have completed their own exercise. The de-briefing
section is useful as it gives the students immediate feedback. However, if
cheating may be a problem you may wish to use DIAGNODB.EXE (supplied with the
full DIAGNOSIS package) in place of DIAGNOSE.EXE. Simply replace one for the
other in the DIAG.BAT file. DIAGNODB.EXE has no visible de-briefing section
(although it is written to the disk file to assist in assessment) so the
students do not know the answer until their scripts are marked.
5. HARDWARE REQUIREMENTS
This will largely depend on the graphic screens teachers wish to build into
their scenarios. Picture files require a graphic "show" program and the more
pictures on a disk the greater the room required. A graphics card will be
also needed and (probably) at least 640K memory.
DIAGNOSE.EXE (and DIAGNODB.EXE) can run without any graphics card from a
single 360K floppy disk in 256k of memory (if no graphics are shown in the
scenario). TITLE.EXE requires the appropriate graphics card but this program
is not essential to the game.
6. SUPPLIED SCENARIOS AND VPIC UTILITY PACKAGE
The source and data files for five scenarios are supplied in the full DIAGNOSIS
package. In the demo version, only one has been supplied. (See appendix 2
for picture file sources). Scenarios can be amended to fit local conditions
as required using an editor and DIAGBLD.EXE.
VPIC is supplied as a utility to the package, and can be used as the "graphic
viewer" if the tutor so wishes. VPIC is registered for use with DIAGNOSIS and
no further payment is required once the full version is paid for. However,
if VPIC is to be used for general file viewing, then it must be paid for
as outlined in the VPIC documentation.
As mentioned earlier in this text, some of the images included in the supplied
scenarios require a card which can display 256 colours in 640 x 480 pixels.
Use of the pre-compiled scenarios on hardware with lower graphics capability
requires amendments to the *.TXT files, changing references to graphic
pictures and files and inserting the word 'none', where these fail to display
properly. Text descriptions may also need elaboration in the absence of a
picture. The *.TXT files would then need to be re-compiled using DIAGBLD.EXE
as explained in part 3 of this text.
Finally, the student manual (STUDENT.DOC) may be edited and modified as the
tutor sees fit.
Happy scenario construction.
DIAGNOSIS (DEMO) ver 1.1 (C) Copyright 1991, Massey University, New Zealand
Author: Terry M. Stewart
Department of Plant Science
Massey University
Palmerston North
New Zealand
All Rights Reserved
APPENDIX 1
Steps for the creation of a new scenario (only possible with the full version)
1. Draw/scan graphic pictures (if any) to be used in scenario and save to
files. Check that the graphic viewing software works correctly and is
configured to whatever machine(s) it will be used on.
2. Make a duplicate of TEMPLATE.TXT, calling it an appropriate name for the
scenario being created, e.g. COPY TEMPLATE.TXT ROSERUST.TXT
3. Edit the new file, inserting all the necessary information
(use PHYTOROT.TXT as a guide).
4. Type DIAGBLD to compile the new file. You will be asked to supply the
input file (e.g. ROSERUST.TXT) and a name for the new Pascal data file
(e.g. CASE5.DAT). Input file may (in fact probably will) need
re-editing if formatting errors exist.
5. Edit the file DISEASE, and change whatever filename it contains to the name
of the new data file (e.g. CASE5.DAT in this example).
6. Decide on whether you wish to have an immediate de-briefing in the game
(using DIAGNOSE.EXE) or not (using DIAGNODB.EXE) and edit DIAG.BAT
accordingly.
7. Prepare a disk or separate directory for the scenario which includes...
* Any graphic files (user supplied)
* VPIC.EXE or a user supplied graphic viewing program
* DIAGNOSE.EXE or DIAGNODB.EXE depending on which you elect to use
* DIAG.BAT (if you have a graphics card)
* TITLE.EXE (if you have a graphics card)
* TITLE.DAT (if you have a graphics card)
* DISEASE
* PLAYER.NM (if you are *not* using TITLE.EXE)
* The Pascal data file containing the scenario
(whose name is in DISEASE (e.g. CASE5.DAT).)
8. Type DIAG (or DIAGNOSE or DIAGNODB if no graphic card) to begin...
APPENDIX 2
Sources of pictures in *.GIF files supplied
0_1.gif From slide collection Massey University NZ 1992
0_2.gif From slide collection Massey University NZ 1992
0_3.gif From slide collection Massey University NZ 1992
0_4.gif From C.M.I. Descriptions of plant pathogenic fungi and bacteria
No. 111
0_5.gif Modified from Microfungi on land plants. An identification handbook.
M.B. and J.P. Ellis. Croom Helm. London and Sydney 1985
0_6.gif From slide collection Massey University NZ 1992
APPENDIX 3
DISCLAIMER
All warranties are disclaimed, including damage to hardware and/or software
from use of this demonstration product. In no event will liability be accepted for any damages arising out of use or inability to use the program, or any other claim by any other party.
